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ARMY  WWMCCS  INFORMATION  SYSTEM  (AWIS) : 

A  STRATEGIC  COMMAND  AND  CONTROL  SYSTEM 

CHAPTER  I 
INTRODUCTION 

A  well  known  saying  states  that:  "Congress  makes  an 
individual  a  General;  Communications  makes  that  individual  a 
Commanding  General."  I  submit  that  a  present-day  version  of  this 
saying  would  state  that  it  is  "information"  that  makes  an 
individual  a  Commanding  General.  The  Army  World  wide  Military 
Command  and  Control  System  Information  System  (AWIS)  will  provide 
this  modern  information  system  capability  in  the  near  future. 

The  World  Wide  Military  Command  and  Control  System  (WWMCCS) 
technically  consists  of  many  loosely  connected  systems  with  the 
mission  of  providing  instantaneous,  accurate  data  and  a  decision 
support  system  to  satisfy  three  primary  missions:  day-to-day 
command  and  control  operations;  crisis  management;  and  critical 
command  and  control  orders  that  must  reach  the  forces.  Figure  1 
diagrams  the  various  elements  of  the  WWMCCS  in  block  format  with 
the  Data  Collection  and  Processing  element  expanded. 1 

One  of  the  WWMCCS  systems  is  the  WWMCCS  Automatic  Data 
Processing  (ADP)  program  with  its  backbone  of  numerous  large- 
scale  Honeywell  DPS 8  host  computers  located  at  all  major 
Department  of  Defense  Command  Centers  throughout  the  world. 

Figure  2  illustrates  WWMCCS  relationships  with  other  non-WWMCCS 
systems.  Thousands  of  work  stations  and  terminals  are  used  to 
build,  update,  and  manipulate  the  information  (data  bases)  stored 
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in  the  host  computers. 2  All  the  host  computers  are 
interconnected  by  a  large,  robust  communications  network  call  the 
WWMCCS  Intercomputer  Network  (WIN) .  Figure  3  illustrates  the 
capabilities  of  WIN. 3  The  WWMCCS  ADP  program  focuses  on  the 
development  and  execution  of  war  plans;  it  emphasizes 
mobilization,  deployment,  employment  and  sustainment  of  the 
force . 

The  WWMCCS  Information  System  (WIS)  was  mandated  by 
Congress  in  the  early  1980s  to  modernize  the  WWMCCS  ADP  program 
and  to  correct  many,  very  serious  deficiencies  in  the  DoD's 
primary  strategic,  go-to-war  system.  The  Air  Force  was  named  the 
executive  agent  to  modernize  the  Joint  WIS  program,  and  each 
service  set  up  a  project  office  to  modernize  its  own  system 
( AFWIS ,  NWIS  and  AWIS) . 

This  study  will  focus  on  the  Army's  AWIS  program  and  will 
trace  AWIS  from  the  original  inception  in  1984  to  the  present. 

In  a  time  of  shrinking  resources,  it  is  very  probable  that  many 
Army  troops  will  be  returned  to  CONUS  and  the  Army  will  purchase 
fewer  and  fewer  weapons  systems.  Major  changes  to  the  Army's 
mission — from  providing  large,  extremely  heavy  forces  to 
deploying  extremely  fast,  light  focused  specialized  troops — will 
increase  the  priority  and  criticality  for  building  and 
modernizing  the  Army's  Strategic  Command  and  Control  System. 

This  study  will  explore  the  AWIS  program  as  a  force 
multiplier  and  a  means  to  more  effectively  mobilize,  deploy, 
employ  and  sustain  a  force.  It  will  analyze  the  status  of  the 
present  AWIS  program  in  light  of  the  recent  reestablishment  of 
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the  Joint  WIS  program  under  the  Defense  Communication  Agency 
(DCA) .  Finally,  the  study  will  make  recommendations  on  suggested 
improvements  in  the  development  and  acquisition  of  program 
software  and  hardware  products. 


MISSION 


The  AWIS  Project  Management  Office  (PMO)  was  chartered  by 
the  Secretary  of  the  Army  and  established  in  1984.  The  Project 
Manager  (PM)  for  AWIS  is  the  Army  component  of  a  joint 
modernization  effort  to  provide  operational  planning  and 
execution  capabilities  for  the  National  Command  Authority  (NCA) 
at  Echelons  Above  Corps  (EAC) .  The  program  identifies 
information  requirements,  develops  an  integrated  architecture, 
and  implements  a  system  to  support  the  mobilization,  deployment, 
employment,  and  sustainment  of  conventional  forces  during  crisis 
and  war.  It  will  provide  information  to  WIS  and  meet  unique  Army 
requirements  as  well. 4 

The  PM  AWIS  is  responsible  for  planning  and  implementing 
the  portion  of  the  WWMCCS  Information  System  (WIS)  supporting  the 
Army  sponsored  Unified  and  Specified  Commands,  the  Army 
Components,  the  Transportation  Operation  Agencies  (TOA) ,  and 
Headquarters,  Department  of  the  Army.  The  PM  is  also  responsible 
for  the  planning,  development,  and  fielding  of  the  Command  and 
Control  (C2)  Army  Theater  Architecture,  which  provides 
information  exchange  from  the  tactical  C2  systems  through  the 
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theater  to  the  strategic  C2  systems  supporting  the  Army 
headquarters  at  EAC. 


On  1  July  1986,  AWIS  and  the  Command  and  Control  Systems 
(CCS)  project  were  merged  to  become  AWIS/CCS  with  all 
responsibilities  of  the  former  PM  CCS  incorporated  into  AWIS. 

The  CCS  project  consists  of  a  group  of  command  and  control 
programs  that  supports  the  battlefield  commander  at  EAC.  This 
merger  was  designed  to  provide  for  total  integration  of  the  ADP 
and  C2  functions  and  to  foster  standardization  and 
interoperability  among  theater  level  commands.  This  expanded 
mission  included: 

-Army  implementor  of  Joint  Operation  Planning  and  Execution 
System  (JOPES) . 

-Identifications  of  C2  transportable  requirements. 

-Fielding  of  two  transportable  C2  systems  for  Europe. 

-Implementing  and  fielding  of  the  Logistics  Network 
(LOGNET) . 

-Fielding  of  a  secret  level  WWMCCS  capability. 5 


WIS  PROGRAM  DESCRIPTION 

In  the  early  1970s,  the  DoD  procured  ADP  equipment  to 
support  decision  making  at  many  of  its  commands  and  to  support 
the  WWMCCS.  This  equipment  became  obsolete  due  to  age  and  out¬ 
moded  technology.  In  the  last  few  years,  the  state  of  the  art 
has  changed  significantly,  since  computer  and  communications 
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equipment  have  become  substantially  smaller,  more  reliable,  and 
less  expensive. 

Plans  and  a  architecture  for  WWMCCS  modernization  were 
developed  and  documented  in  reports  to  Congress  in  1980,  1981, 
and  1982.  The  General  Accounting  Office  (GAO)  also  conducted 
investigations  into  needed  improvements  in  the  system.  Their 
concerns  were  included  in  a  1982  report  to  Congress  and  are 
listed  in  Figure  4. 

In  November  1981,  the  Chief  of  Staff  of  the  Air  Force  was 
designated  as  the  Executive  Agent  for  the  WIS  modernization 
program;  in  January  1982,  he  appointed  a  WIS  PM  to  be  responsible 
for  continuing  WIS  development.  The  Joint  Program  Manager  (JPM) 
assigned  top  priority  to  systems  that  performed  standard  (joint 
missions)  command  and  control  functions.  Systems  that  performed 
service  or  command  unique  functions  would  be  the  responsibility 
of  the  individual  service  and  would  be  developed  in  close 
coordination  with  the  joint  WIS  community.  Figure  5  depicts  the 
incremental  development  concept. 6 

WIS  consists  of  the  software,  hardware,  integrated  support 
and  connectivity  necessary  to  facilitate  planning,  directing, 
coordinating,  monitoring,  and  controlling  conventional  military 
operations.  The  scope  of  the  WIS  program  is  to: 

-Modernize  WWMCCS  standard  AOP  and  directly  related 
telecommunications . 

-Support  the  modernization  of  the  C2  systems  for 
conventional  operations,  both  joint  and  service,  and  command 
unique  portions. 
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FIGURE  5 

:CS/AWIS  DEVELOPMENT 


-Support  the  tasks  required  during  mobilization, 
deployment,  employment,  and  sustainment  activities  to  include 
monitoring,  planning,  and  execution  for  peacetime,  crisis,  and 


wartime  operations. 7 


AWIS/ CCS  PROGRAM  OBJECTIVES 


The  authority  for  requirements  development  and  contract 
efforts  are  set  forth  in  the  following  two  documents: 

" (The)  detailed  information  needs  of  WWMCCS  nodes  must  be 
addressed. . .The  services  must  take  the  lead  and  ...collect  the 
necessary  requirements  of  WWMCCS  nodes . " 

Assistant  Secretary  of  Defense 
2  April  1981 

"The  services  (will)  conduct  (requirements)  interviews  at 
the  operations  centers  and  headquarters  of  their  respective 
services.  Unified  and  Specified  Commands,  Component  Commands  and 
TOAs . " 

Office  of  the  Joint  Chiefs  of  Staff 
3  June  1981 

When  tasked  in  1983,  the  AWIS  mission  was  limited  to  the 

modernization  of  the  eight  WWMCCS  sites  under  the  operational 

control  of  the  Department  of  the  Army.  The  modernization  effort, 
* 

as  siandated  by  Congress,  was  to  address  hardware,  software, 
communications,  procedures,  policy  and  processes.  The  PM  AWIS 
was  further  responsible  to  insure  that  an  orderly  and  effective 
transition  was  effected.  This  transition  was  to  be  accomplished 
without  any  degradation  to  the  capabilities  of  the  existing 
Army's  WWMCCS  ADP  system. 
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Over  time,  additional  sites,  projects,  and  products  have 
been  tasked  to  the  PM;  together,  they  form  a  program  of 
modernization  for  C2  at  Theater  (EAC)  and  Army  Major  Commands  as 
shown  in  Figure  6.  The  center  of  the  diagram  cites  products 
being  developed  that  are  used  not  only  to  support  the  Army  WWMCCS 
improvement  mission  but  also  to  support  command  centers,  EAC 
programs  and  other  Army  command  unique  requirements . 8 

AWI S/CCS  SYSTEMS  ARCHITECTURE 

The  AWIS  will  be  a  substantially  modernized,  improved,  and 
expanded  version  of  the  support  capabilities  provided  by  existing 
WWMCCS  ADP  and  related  telecommunications  components.  The 
modernization  will  involve  a  major  redesign  and  replacement  of 
existing  WWMCCS  components,  over  time,  in  an  incremental  and 
evolutionary  strategy  that  will  reduce  manpower  and  maintenance 
requirements,  make  it  less  expensive  to  maintain  and  more 
responsive  and  reliable  to  user  needs.  AWIS  has  an  established 
architectural  design  that  includes  implementation  of  hardware, 
software,  communications  interfaces,  and  data  bases  to  support 
joint  mission  systems.  Specifically,  the  AWIS  architecture 
contains: 

-A  Local  Area  Network  (LAN)  for  local  connectivity. 

-A  mechanism  and  protocols  for  linking  in  the  WIN  and 

Digital  Data  Network  (DDN) . 

-A  Common  User  Subsystem  (CUS)  for  Automated  Message 
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AWIS/CCS  TWO  PARTS  BUT  ONE  PURPOSE 
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FIGURE  6 


Handling  (AMHS) ,  electronic  mail,  user  terminal  hardware  and 
software  support,  and  data  base  services. 

-Joint  mission  software  design,  development,  and 
implementation. 

-Joint  mission  hardware  and  ADP  security. 9 
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CHAPTER  II 


AWIS  HARDWARE  DEVELOPMENT 

The  Joint  WIS  program  had  been  inefficiently  managed  in  the 
past  years.  Consequently,  it  has  been  transferred  from  the  Air 
Force  to  the  Defense  Communication  Agency  (DCA) .  Unfortunately, 
the  Army's  program  to  modernize  the  service  portion  of  WWMCCS  has 
suffered  by  association.  The  joint  program  is  needed  to  provide 
capstone  JCS  level  hardware  and  software.  Even  so,  the  AWIS 
program  will  now  be  managed  by  a  new  authority  in  order  to 
continue  to  provide  enhanced  C 2  capability  to  the  Army  in  support 
of  its  strategic  and  EAC  missions. 1 


BACKGROUND 

The  joint  program  was  designed  to  provide  the  joint 
hardware  depicted  in  Figure  7.  The  AWIS  program  was  to  be 
responsible  for  all  additional  hardware  that  was  not  provided  by 
the  joint  program  and  to  develop  and  plan  for  the  integration  and 
transition  of  the  service  system  into  the  new  WIS/ AWIS  world. 

The  evolutionary  WIS  joint  program  acquisition  strategy 
would  establish  a  core  capability  and,  through  iterative  blocks, 
continually  upgrade  that  core.  The  recent  decoupling  of  the 
joint  program's  initial  block  A  upgrade  necessitated  that  the 
AWIS  program  develop  its  own  hardware  fielding  plan,  shown  in 
Figure  8. 
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Honeywel 1  Equipment 

Equipment  will  continue  to  be  fielded  from  the  existing 
WWMCCS  Honeywell  contract.  The  contract  includes  the  upgrade  of 
host  processors  currently  at  the  AWIS  sites,  memory  upgrades 
required  for  GC0S8 ,  DATANET8  for  LAN  connectivity,  and 
replacement  equipment  to  reduce  the  footprint  at  all  sites.  This 
contract  expires  in  1991  but  will  most  likely  be  extended  again. 

Early  Products  Wo rksta t i ons 

The  early  products  workstations  contract  with  IBM  expired 
in  December  1988.  A  workstations  contract  was  awarded  in 
November  1988,  and  tempest  workstations  were  fielded  beginning  in 
July  1989. 

Local  Area  Network  (LAN) 

GTE  is  responsible  for  the  development  and  installation  of 
the  AWIS  Local  Area  Network  (LAN).  The  installation  of  a  LAN  at 
an  Army  operational  test  site  is  scheduled  to  begin  in  November 
1990. 


Automatic  Message  Handling  System  (AMHS) 

The  Automatic  Message  Handling  System  (AMHS)  is  presently 
under  development  and  scheduled  to  be  installed  in  November  1990. 
Only  the  Army  Operations  Center  (AOC)  has  an  AMHS  capability,  but 
their  message  handler  is  considered  unsatisfactory.  One  of  its 
major  shortfalls  is  the  delay  in  message  delivery  during 
exercises.  Often  as  many  as  2,000  messages  are  received  each 
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day,  leading  to  delayed  delivery  and  mishandling  problems.  The 
improved  AMHS  will  provide  the  capability  to  receive  messages 
from  AUTODIN  and  have  them  routed  to  an  action  officer  at  his 
workstation  based  upon  keyword  profiling.  This  reduces  risk  and 
significantly  reduces  the  time  to  receive  and  transmit  message- 
sensitive  information. 2  Figure  9  itemizes  AMHS  capabilities. 

RECOMMENDATIONS 


The  US  Army  War  College  (USAWC)  Strategic  Wargaming 
Facility  (SWF)  is  presently  in  the  initial  planning  stage.  The 
purpose  of  this  facility  is  to  provide  a  conference  center  to 
support  the  Army  Chief  of  Staff  and  CinCs  for  symposia,  meetings, 
and  wargaming  sessions  in  an  academic  environment. 3  The  mission 
of  this  facility  is  illustrated  in  Figure  10.  The  SWF  would  be 
the  ideal  Army  operational  test  site  for  the  development  and 
installation  of  both  the  top  secret  LAN  and  the  AMHS.  This 
multifaceted  facility  would  provide  an  extended  capability  for 
AWIS  software  products  to  be  run  on  WWMCCS  equipment  and  to  test 
and  use  techniques  developed  for  command  center  projects.  The 
combination  would  create  a  synergistic  effect  for  all  these 
efforts. 4 


ENDNOTES 


1.  Interview  with  James  White,  COL,  Project  Management  Office 
AWIS,  Fort  Belvoir,  Virginia,  7  October  1989. 

2.  Interview  with  James  Bray,  Project  Management  Office  AWIS, 
Fort  Belvoir,  Virginia,  10  November  1989. 
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.Int®r^e^  with  Ernest  A.  Levassuer,  COL,  Project  Management 
Office  SWF,  Carlisle  Barracks,  Pennsylvania,  28  October  1989. 


4  Interview  with  Robert  Brynildsen,  Project  Management  Office 
AWIS,  Fort  Monmouth,  New  Jersey,  12  January  1990. 


CHAPTER  III 


AWIS  SOFTWARE  DEVELOPMENT 

AWIS  software  products  are  critical  to  the  success  of  the 
Army's  WWMCCS  ADP  modernization  effort.  The  foundations  upon 
which  AWIS's  software  development  were  originally  based  have 
radically  changed.  Restructuring  of  the  joint  program  along  with 
repeated  slips  in  key  deliveries  of  all  joint  products  have 
together  necessitated  a  review  of  AWIS's  software  development 
strategies . 


BACKGROUND 

The  upper  portion  of  Figure  II  illustrates  the  current 
WWMCCS  environment,  which  is  based  on  1960s  technology. 

Standards  are  nonexistent  and  multiple  computer  languages  create 
a  barrier  for  the  user  in  obtaining  time  sensitive  information. 
To  obtain  needed  information,  application  programmers  are 
required  to  write  routines  often  requiring  extensive  resources 
and  weeks  to  months  of  delay.  Currently,  over  12  million  lines 
of  code,  with  duplicative  functionality,  are  installed  at  Army 
sites.  Software  maintenance  costs  have  become  intolerably 
expensive. 

The  lower  portion  of  Figure  11  depicts  the  AWIS  objective 
system.  AWIS  will  accommodate  the  user's  requirement  for  a 
highly  interactive,  user-friendly,  on-line  query  and  retrieval 
capability.  The  program  will  produce  a  sophisticated  user 
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accessible  data  base  that  has  a  Standard  Query  Language  (SQL)  and 
a  data  dictionary.  The  existing  12  million  lines  of  code  will  be 
replaced  with  some  3  million  lines  of  Ada.  In  addition  to  the 
critically  needed  increased  functionality,  the  life  cycle 
maintenance  savings  are  expected  to  total  $.5  billion.l 

SOFTWARE  CONTRACT 

The  AWIS  Software  Development  (ASD)  contract  was  awarded  in 
January  1987  to  the  TRW  Corporation.  The  contract  is  currently 
in  Option  Year  Two,  with  an  estimated  completion  date  of  March 
1993.  The  timeline  of  the  contract  is  shown  in  Figure  12. 

The  contract  should  provide  a  Full  Scale  Development  (FSD) 
effort  for  AWIS,  which  includes  defining,  designing,  developing, 
documenting,  and  deploying  into  full  operation  a  core  of 
functional  software  products.  The  software  products  will  support 
Army  WWMCCS,  command  centers,  and  echelons  above  corps  C2 
software  requirements.  The  FSD  effort  will  also  meet  the 
requirment  to  flow  information  to  and  from  Army  theater  tactical, 
sustaining  base,  and  JCS  systems.  In  addition,  the  contract 
calls  for  acquiring  a  production  quality  Ada  Program  Support 
Environment  (APSE)  along  with  the  necessary  automated  tools  to 
provide  the  functionality  needed  for  a  large  scale  development. 
Figure  13  illustrates  the  proposed  APSE. 2 
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FIGURE  13  Ada  Program  Support  Enviorment  (APSE) 


PRODUCT  LINES 


The  ASD  Phase  I  task  was  based  on  an  extensive  analysis  of 
C2  functions  that  apply  across  all  commands.  This  effort 
dramatically  decreased  the  amount  of  software  needed;  it  as  well 
established  a  requirement  for  the  software  product  lines  listed 
in  Figure  14. 

To  develop  these  software  product  lines,  a  prototyping 
approach  is  being  used  to  reduce  risk  and  to  incrementally 
validate  use  requirements.  The  goal  is  for  early  delivery  of 
operational  prototypes;  they  will  be  released  in  segments  of  100K 
lines  of  code  so  that  improved  capability  can  be  fielded  quickly. 
The  overall  AWIS  software  Master  Plan  is  shown  in  Figure  15. 

The  first  release  of  the  Movement  Control  and  Readiness 
Reporting  (MCRR)  product  line  was  fielded  to  USAREUR  for  use  in 
the  WINTEX  '89  FTX .  The  first  release  of  Mobilization  and 
Deployment  (MOB/DE)  product  line  was  fielded  to  FORSCOM  in 
September  1989.  Likewise,  the  Unit  Status,  Logistics,  Personnel, 
C3  Management,  and  Operations  product  lines  are  now  under 
development  with  releases  scheduled  to  the  field  in  1990. 

The  importance  of  the  AWIS  program  effort  to  the  senior 
leadership  of  the  Army  can  be  substantiated  in  a  letter  sent  to 
the  AWIS  Project  Management  Office  (PMO)  by  LTG  Ross.  After 
having  been  briefed  on  the  Logistics  products  line,  LTG  Ross 
wrote, 

...the  development  of  this  new  capability  is  of  unique 
importance  to  the  Army.  For  the  first  time,  the 
critical  Joint  Operational  Planning  and  Execution 
System  (JOPES)  logistics  command  and  control  functions 
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FIGURE  15 


of  HQDA  and  the  Army  major  commands  will  be  performed 
as  part  of  an  Army  standard  system. 

LTG  Ross 
DC SLOG 
26  May  1989 

The  AWIS  software  development  effort  is  a  $100  million+ 
Ada-based  program  that  is  modernizing  strategic  Army  C2  software. 
While  current  efforts  are  site-oriented,  it  is  planned  that 
subsequent  software  modules  will  be  developed  and  fielded  on  a 
functional  basis  usable  by  multiple  Army  WWMCCS  sites. 

The  original  program  was  structured  with  very  tight 
schedule  and  programmatic  linkages  to  capabilities  and 
architectures  that  were  to  have  been  provided  to  AWIS  by  the 
joint  program.  With  the  recent  transfer  of  the  joint  program, 
those  linkages  are  now  essentially  "broken".  This  has  made  the 
AWIS  software  program  especially  challenging.  In  addition  to  the 
breakage  of  joint  program  linkages  cited  above,  other  significant 
challenges  remain: 

-The  necessity  for  rapid  software  development  in  the 
absence  of  total  system  engineering. 

-The  difficulty  of  incrementally  implementing  a  modern 
Relational  Database  Management  Environment  (RDBME)  while  AWIS 
sites  continue  to  use  various  obsolete  DBMSs. 

-The  understated  complexity  of  fielding  and  transition. 

-The  continuing  immaturity  of  WWMCCS-qualif ied 
Honeywell /Bull  Ada  products  and  tools  for  large-scale  data  base 
applications. 
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-The  need  to  continue  to  operate  in  an  ill-defined, 
evolving,  and  pol itical ly-sensitive  joint  software  environment . 3 


RECOMMEND  ATI  ONS 


Recommend  the  following  three  mutual ly-supportive,  top- 
level  goals  form  the  basis  for  all  future  AWIS  software 
development  efforts: 

-Goal  #1:  Sustain  the  program's  momentum. 

-Goal  #2:  Build  robust,  reusable  systems. 

-Goal  #3:  Emphasize  fielding  and  transition. 

Figure  16  illustrates  an  overview  of  this  approach. 

Goal  #1:  Sustain  the  Program's  Momentum 

The  AWIS  program  has  historically  been  successful.  The  PMO 
has  had  many  successes  in  putting  hardware  on  the  ground,  has 
several  innovative  programs  underway,  and — unlike  the  joint 
program — has  an  extensive  functional  requirements  baseline. 
However,  any  lengthy  delays  in  software  deliveries  will  quickly 
dampen  enthusiasm  from  the  field  for  the  project.  Long  delays 
inherent  in  the  traditional  waterfall  model  approach  to  software 
development,  illustrated  in  Figure  17,  will  lessen  support  even 
more. 4 

The  challenge  is  to  maintain  the  momentum  of  the  program 
and  garner  user  support  while  continuing  to  do  long-term  system 
development  on  AWIS  software  product  lines.  Careful  management 
of  prototyping  activities  will  produce  great  payoffs  in  fostering 
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FIGURE  17  Waterfall  Model 


user  enthusiasm  for  the  program  and  will  also  assist  in 
continuing  the  program  momentum. 

Spi ral  Model 

The  spiral  model,  developed  by  Dr.  Barry  W.  Boehm,  has  been 
successfully  applied  to  a  number  of  large-scale  programs.  Figure 
18  portrays  this  model  in  its  basic  format. 

This  model  is  a  risk-driven  approach  that  emphasizes 
prototyping  and  incremental  deliveries  to  allow  a  more  realistic 
approach  to  requirements  satisfaction.  It  provides  structure  to 
the  concept  of  "design  a  little,  build  a  little"  and  allows 
evaluation  and  feedback  on  each  cycle  of  software  development. 
Each  spiral  model  cycle  follows  the  same  sequence  of  steps: 
designate  objectives,  alternatives  and  constraints;  evaluate 
alteratives  and  resolve  risks  relative  to  objectives  and 
constraints;  develop  the  appropriate  product;  then  review  and 
plan  the  next  cycle.  This  provides  a  flexible,  iterative  answer 
to  the  problem  of  inherently  long  delays  during  software 
development.  It  has  the  following  particularly  positive 
features : 

-It  fosters  the  development  of  specifications  that  are  not 
necessarily  uniform,  exhaustive,  or  formal,  in  that  it  defers 
detailed  elaboration  of  low-risk  software  elements  and  avoid 
unnecessary  breakage  in  design  until  the  high-risk  elements  of 
the  design  are  stabilized. 

-It  incorporates  prototyping  as  a  risk-reduction  option  at 
any  stage  of  development. 5 
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-It  accommodates  reworks  or  go-backs  to  earlier  stages  as 
more  attractive  alternatives  are  identified  or  as  new  risk  issues 
need  resolution. 

-It  focuses  early  attention  on  options  involving  the  reuse 
of  existing  software.  The  steps  involving  the  identification  and 
evaluation  of  alternatives  encourages  these  options. 

-It  accommodates  preparation  for  life  cycle  evolution, 
growth,  and  changes  of  the  software  product.  The  major  sources 
of  product  change  are  included  in  the  product’s  objectives. 

-It  provides  a  mechanism  for  incorporating  software  quality 
objectives  into  software  product  development.  This  mechanism 
derives  from  the  emphasis  on  identifying  all  types  of  objectives 
and  constraints  during  each  round  of  the  spiral . 

-It  focuses  on  eliminating  errors  and  unattractive 
alternatives  early.  The  risk-analysis,  validation,  and 
commitment  steps  cover  these  considerations. 

-It  does  not  involve  separate  approaches  for  software 
development  and  software  enhancement. 

-It  provides  a  viable  framework  for  integrated  hardware- 
software  system  development. 6 

Prototyping 

The  term  "prototyping"  is  wrongly  assumed  by  many  to 
encompass  only  early  software  delivery.  The  early  cycles  of 
prototyping — which  allows  for  better  understanding  of  user 
requirements  (the  greatest  risk  in  software  development)  and  for 
mitigating  later  design  risks— are  either  ignored  or  not 
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understood.  Such  an  exclusive  orientation  to  only  so-called 
"rapid"  prototyping  puts  user  expectations  on  a  collision  course 
with  what  actually  must  occur  with  prototyping  as  a  normal  part 
of  modern  software  engineering. 

The  various  stages--demonstration  through  operational— of 
prototyping  and  their  relationship  to  software  development  must 
be  institutionalized  in  a  consistent  manner.  The  software 
development  effort  must  provide  a  standardized  approach  to 
prototyping,  its  use  for  risk  mitigation,  and  its  relationship  to 
the  overall  software  life  cycle. 7 

Demonstration  Prototyping 

This  work  is  currently  being  managed  in  an  ad  hoc  manner. 
Each  site  team  is  now  prototyping  different  user  interfaces  at 
various  levels  of  detail.  Demonstration  prototyping  must  be 
refocused  in  direct  support  of  software  product  lines  under 
development. 

Demonstration  prototyping  activities  must  be  placed  under 
tight  centralized  control,  must  be  made  an  integral  part  of  the 
systems  development  process,  and  must  be  managed  separately  from 
operational  prototyping.  It  should  be  used  for  front-end  risk 
mitigation  of  user  requirements  and  refinement  of  user-oriented 
operational  concepts. 

While  demonstration  prototyping  is  clearly  cyclic  and  will 
still  be  required  throughout  the  software  life-cycle,  the  bulk  of 
it  supporting  current  software  products  lines  must  be  completed 
as  quickly  as  feasible;  then  those  demonstration  resources  should 
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be  redirected  to  supporting  centralized/decentralized  operational 
prototyping. 

Operational  Prototyping 

This  activity  offers  high  returns  for  the  program,  since 
software  can  be  developed  and  fielded  early,  as  end-user's 
operational  needs  dictate.  Therefore,  the  majority  of  available 
prototyping  resources,  both  at  the  central  design  facility  and  at 
sites,  should  be  ultimately  targeted  to  operational  prototyping. 
Operational  prototyping  should  be  given  the  strongest  emphasis, 
managed  as  an  integral  part  of  the  software  development  process, 
and  targeted  to  so-called  "high  payoff"  prototypes. 

"High  payoff"  prototypes  must  satisfy  an  unfulfilled  need, 
have  fairly  simple  data  needs,  be  reusable  across  sites,  and 
ideally  be  workstation-based.  These  operational  prototypes 
should  evolve  into  the  nucleus  of  a  future  software  product  line 
and  must  be  derived  from  an  appropriate  functionally  baselined 
software  requirement  specif ication. 8 

Goal  >2:  Build  Robust,  Reusable  Software 

Software  development  is  the  essence  of  the  AWIS  program. 
Special  emphasis  must  be  placed  on  the  areas  of  system 
architecture,  incremental  development  planning,  and  software  and 
data  base  design. 

AWIS  System  Architecture  Definition 

Most  of  the  assumptions  upon  which  the  Phase  I  program  was 
structured  have  changed.  The  net  effect  of  these  changes,  nearly 
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of  which  are  external  to  the  program,  has  been  to  compound 
overall  software  design  risks.  The  program  has  been  reacting  in 
a  piecemeal  fashion  to  such  changes  without  a  coordinated, 
consistent  architectural  viewpoint. 

Accordingly,  the  top  Phase  II/Option  Year  Two  priority  must 
be  the  definition  of  a  pragmatic,  realistic  and  affordable  basic 
AWIS  system  architecture.  A  generic  architecture,  illustrated  in 
Figure  19,  must  be  developed  in  accord  with  this  guidance: 

-The  architecture  will  initially  be  Honeywell /Bull  based 
and  must  use  only  existing  WWMCCS-certif ied  products. 

-Current  "systems-high"  operation  will  be  the  baseline 
security  architecture  with  evolution  to  split  "systems-high." 

-The  architecture  must  make  conservative  assumptions  about 
the  availability  of  other  vendors'  products  and  should  take  an 
"open  systems"  orientation. 

-It  will  be  "loosely  coupled"  to  joint  developments  and 
defined  in  detail  where  assumed/critical  linkages  exist. 

-Progression  toward  a  relational  database  environment  using 
the  following  criterions  is  required: 

— AWIS  workstations  must  be  a  key  component  and 
evolution  to  distributed  databases  operating  on  these 
workstations  is  desired. 

— Quick  migration  to  a  relational  database 
environment  with  a  RDBME  accessed  via  an  AWIS  LAN  with 
workstation  must  be  shown. 

— Management  Information  Systems  (MIS)  impacts  on 
standard  Army  C2  software  must  be  considered. 
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FIGURE  19  Generic  Architecture 


— The  architecture  must  take  cognizance  of  DCA’s 
plans  in  the  reorganization  effort  and  integrate  AWIS's  various 
LAN  and  AMHS  initiatives  on  a  time-phased  basis. 

This  architecture  should  be  a  "living"  one,  frequently 
updated  and  integrated  into  the  system  engineering/development 
process  that  forms  the  basis  of  all  subsequent  development 
activities . 

Incremental  Development  Plan 

An  Incremental  Development  Plan  (IDP)  that  supports  the 
architecture  is  required  and  should  be  the  foundation  for  all 
subsequent  program  activities.  Current  software  developments 
must  be  integrated  into  the  build  sequence.  The  IDP  must  be 
finalized  together  with  the  AWIS  systems  architecture  and  should 
augment  it. 

The  IDP  should  also  identify  opportunities  for  possible 
later  involvement  of  site  resources  in  the  development  of  site 
software  that  may  be  required  to  fully  field  functional  product 
lines.  It  must  evolve  the  system  architecture  into  detailed 
site-by-site  architectures  and  fielding  schedules. 

Software  Design 

The  software  design  assumptions  upon  which  the  program  was 
based  are  not  yet  institutionalized  in  the  program's  current 
system  engineering  methodology.  A  software  design  philosophy 
should  be  developed  with  the  following  provisions: 


-A  layering  philosophy  as  illustrated  in  Figure  20  that  has 
goals  of: 

— Making  applications  programs  independent  from 
vendor-specific  hardware  and  software. 

— Isolating  application  programs  from  the  data 

architecture . 

-The  use  of  Commercial  Off-The-Shelf  (COTS) ,  modified  COTS, 
and  custom  packages,  at  all  levels  to  allow  users,  if  possible, 
to  solve  their  own  problems  via  ad  hoc  query  and  minimize  the 
need  for  massive  application  software  maintenance. 

-Allowing  users/site  personnel  the  flexibility  to  build  and 
alter  application-specific  Input/Output  (I/O)  screen  dynamically 
by  identifying  and  providing  the  tools  to  do  so. 

-Addressing  the  resolution  of  interface  conflicts  and  the 
establishment  of  formal  software  interface  control  procedures. 

Additionally,  the  desired  software  design  approach  must 
specify  how  to  provide  the  core  software  necessary  for  users  to 
do  their  jobs  while  integrating  tailorable  front-ends  into  the 
design  to  accommodate  later  changes  in  user's  functionality. 

Data  base  Design 

The  relational  environments  and  Ada-SQL  bindings  which 
seemed  quite  reasonable  assumptions  at  the  initiation  of  the 
program  are  not  yet  available.  On-going  data  administration 
(WISDIM-A)  activities  must  be  better  defined  and  integrated  with 
software  developments  so  that  full  supportable  packages  from  a 
data  administrator's  viewpoint  are  fielded.  Accordingly ,  the 
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following  data  base  design  strategies  should  be  followed: 

-Initially,  an  effort  must  be  made  to  design  software  to 
operate  in  both  the  hodgepodge  of  existing  network  and  flat  file 
DBMS  environments  currently  at  sites  as  well  as  a  modern 
relational  data  base  environment. 

-Several  areas  of  data  base-oriented  prototyping  in 

I 

accordance  with  the  risk  mitigating  methodology  of  the  spiral 
^  model  must  be  made  an  integral  part  of  the  program: 

— Prototyping  must  use  the  most  current  commercial 
GCOS-8  products  to  specify  transition  risks  if  and  when  those 
products  become  WWMCCS-certif ied. 

— Fielding,  development,  and  data  base  design 
should  make  no  assumptions  about  future  product  availability  from 
any  vendor. 

— Incremental  development  and  prototyping  of  the 
ultimate  relational  data  base  design  must  be  done  in  a  RDBME 
prototyping  central  design  facility. 

— Distributed  data  base  management  systems  should 
also  be  investigated  in  parallel  with  database  design  prototypes. 

-A  better  understanding  of  the  data  needs  of  the  various 
on-going  non-AWIS  (joint)  prototypes  is  required.  Their 
existence  cannot  be  ignored  and  their  impacts  must  be  factored 
«  into  the  overall  global  database  design. 9 

Goal  #3:  Emphasis  Fielding  and  Transition 

Fielding  and  transition  are  the  most  visible,  but  currently 
the  least  understood,  aspects  of  the  AWIS  software  effort. 
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Fielding  and  transition  levels  of  effort  are  frequently  neglected 
in  the  current  program.  Left  unaddressed,  they  may  overwhelm  the 
program. 


The  program  has  to  better  distinguish  and  control  "site- 
specific”  as  opposed  to  "system-wide"  fielding  activities.  Both 
must  be  aggressively  managed  as  distinct  yet  mutually 
complementary  activities. 

Site-specific  Fielding 

The  program  must  produce  and  field  functional  software  that 
can  be  cost-effectively  reused  across  many  sites.  Site-specific 
fielding  plans  must  therefore  address: 

-Identification  of  software  build  orders  that  consider 
their  data  dependencies  as  well  as  their  fielding  feasibility, 
given  an  evolving  user-requirements  baseline  and  an  evolving 
global  relational  database  design. 

-Problems  inherent  in  trying  to  design  and  implement  a 
modern  relational  database  management  system  at  a  site  that  must 
continue  parallel  operation  using  a  variety  of  obsolete  network 
DBMSs  and  flat  files. 

-Development  of  expendable,  site-specific  transition 
software  to  field  selected  product  lines. 

-Delineation  of  mutual  fielding  and  transition 
responsibilities  between  the  various  site  support  teams  and  site 
programming/ maintenance  staffs. 
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System-wide  Fielding 

System-wide  fielding  must  include  closer  coordination  with 
JOPES  development,  synchronization  with  joint  data  base 
transition  plans,  and  establishment  of  a  TRW  organization 
focus  on  fielding  and  transition. 

The  current  edition  of  DCA's  WWMCCS  ADP  Modernization  Plan 
(WAMP)  cites  the  new  role  DCA  will  play  as  the  government's 
systems  integrator.  Previous  AWIS  problems  encountered  while 
working  with  the  now  disestablished  JWIS  PMO  are  well  known;  they 
included  the  repeated  inability  to  influence  global  design 
decisions  that  clearly  impacted  AWIS. 

The  WAMP  does  not  explicitly  take  cognizance  of  service 
modernization  programs  nor  does  it  address  how  joint  and  service- 
unique  transition  and  fielding  will  be  synchronized.  System 
engineering  and  integration  concerns  appear  to  be  limited  to 
joint  activities  only.  AWIS  must  make  it  a  matter  of  top 
priority  to  establish  close  coordination  and  foster  a  cooperative 
environment  with  the  DCA  program. 

TRW  currently  has  no  single  organizational  focal  point  that 
has  fielding  and  transition  responsibility.  One  must  be 
established  and  should  be  staffed  with  a  mix  of  developers, 
system  integrators,  and  site-knowledgeable  personnel. 10 
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CHAPTER  IV 


CONCLUSIONS  AND  RECOMMENDATIONS 

Through  the  modernization  of  strategic  communications  and 
ADP  hardware  and  software,  AWIS  will  provide  commanders  with  a 
modernized,  reliable,  operationally  enhanced  capability. 
Commanders  will  be  able  to  rapidly  determine  unit  availability 
and  readiness  and  assess  force  sustainment  capabilities  and 
shortfalls.  AWIS  will  provide  real-time  information  in  a  secure 
environment  with  the  NCA,  CinCs,  services  and  other  agencies;  it 
will  allow  the  manipulation  of  critical  information  to  support 
the  unique  needs  of  decision  makers.  In  addition,  AWIS  will 
provide  the  capability  to  track  the  status  of  troop  mobilization 
and  deployment  from  home  station  to  theater  and  exercise  command 
and  control  of  critical  resources  throughout  the  mobilization  and 
deployment  process. 


CONCLUSIONS 


AWIS  is  a  high  leverage  program  that  is  delivering  critical 
hardware  and  software  products  to  major  Army  commanders  and  CinCs 
to  satisfy  their  documented  requirements.  The  C2  void  at  EAC  is 
being  filled  with  products  from  both  the  Army  Command  and  Control 
System  (ACCS)  program  and  AWIS.  The  integration  of  hardware  and 
software,  not  now  existing  in  many  functional  areas,  will  permit 
resource  based  planning  and  execution  that  will  provide  synergism 
and  enhance  combat  power.  Standardization  will  lower  life  cycle 
costs  and  improve  the  Army's  war  fighting  ability  by  reducing  the 
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learning  curve  for  use  of  automated  systems  in  major  command 
centers  and  at  EAC. 

Hardware 

The  original  AWIS  program  was  largely  software  oriented. 
With  the  present  reestablishment  of  the  Joint  WIS  program  office, 
the  question  of  hardware  development  has  significantly  increased 
in  importance.  The  AWIS  program  must,  in  the  interim,  develop 
required  hardware  in  order  to  continue  to  provide  enhanced  C2 
capabilities  to  the  Army.  Without  a  viable  development  plan, 
hardware  could  become  the  weak  link  in  the  overall  AWIS  program 
chain. 

Software 

The  overall  thrust  of  the  software  development 
recommendations  calls  for  for  a  rapid  move  by  AWIS  to  an  "open 
systems"  distributed  relational  data  base  architecture,  a 
greater  emphasis  on  user-oriented  applications,  a  heavier 
reliance  on  prototyping  as  the  primary  vehicle  to  mitigate  risk 
and  validate  user  requirements,  targeting  of  early  delivery 
operational  prototypes,  more  frequent  and  incremental  product 
deliveries,  and  a  stronger  commitment  to  fielding  and  transition. 

RECOMMENDATIONS 

The  AWIS  program  concerns  and  goals  outlined  in  this  study 
as  well  as  related  recommendations  and  implementation  strategies 
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are  realistic,  sound  and  relevant  to  the  overall  program. 
Recommend  that  these  goals,  general  policies  and  strategies  be 
used  as  the  basis  for  further  detailed  program  planning  and 
execution. 
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